A Consideration of Prolog

Previous analyses of Prolog as a programming language have adopted both theoretical and empirical perspectives. Additionally, the uniqueness of the language has elicited many subjective comments. The result is an inconsistent collection of often contradictory statements. Within this muddle, this paper attempts to outline a more consistent statement of the usefulness of Prolog as a programming language. The analysis is mostly empirical and considers the features of Prolog which have or will prove useful for specific applications areas. A discussion of similarities and differences between Prolog and Lisp is also presented. Finally, some subjective statements about the future of Prolog are considered A Consideration of Prolog 1. Levels of Analysis An analysis of Prolog as a programming language can be conducted on several quite distinct levels. On one level, one can look at an assortment of problems that have been solved using other programming languages, attempt to solve them using Prolog, and compare the resulting solutions (or failures) with the other languages along such dimensions as efficiency of code, speed of execution, reliability, understandability (of the code), etc. Then based on this experience one can make generalizations about the relative usefulness of the respective languages. One might call this approach the empirical method. On a different level, one can look at the theoretical roots of the respective languages and draw conclusions about the elegance and usefulness of the languages based on the theories which led to their implementation. This approach can be called the theoretical method. Each of these two approaches provides a different perspective, but if the approaches are valid, then the results of the analyses should be consistent. Unfortunately, this is not the case. Prolog has proponents and detractors who support their positions with both theoretical and empirical arguments. Further, Prolog has also been examined on a quite different level which relates to the impact Prolog has had on the Artificial Intelligence and computing community. On this level, the subjective level, researchers have provided their subjective evaluations of Prolog’s impact and potential for future impact. On this level inconsistencies abound and Prolog might be said to be “all things to all people”. A review of the literature reveals that most articles which analyze Prolog in isolation or in comparison with other languages (typically functional programming languages like Lisp) do so on one of these three levels with perhaps some mixing of theory into the empirical approach. For example, Carl Hewitt’s (Hewitt, 1985) article, “The Challenge of Open Systems” is a theoretical analysis of logic programming methods. He argues that such methods are inadequate for modeling inconsistent worlds and further that intelligent systems must deal with inconsistency. Thus, from a theoretical perspective he argues against the usefulness of logic programming languages within AI. He makes the strong statement that “logic programming has some fundamental limitations that preclude its becoming a satisfactory programming methodology” (ibid 1985, p. 239). It is interesting to note that this is the position of the designer of Planner, a logic programming language and predecessor of Prolog. From a more empirical perspective, Drew McDermott (1980) discusses various features of Prolog which make it a useful language for certain applications. He notes that Prolog’s provision of an excellent pattern matcher and assertional database make it unnecessary for the user to implement them. He notes that the efficient implementations of Prolog achieved in the last few years make it competitive with Lisp for many applications. He provides several examples of Prolog code and discusses the elegance of the code. Not surprisingly, he notes that Prolog is not efficient for performing such operations as finding the roots of quadratic equations. On the other hand, the implementation of the relation “append” is quite elegant reflecting the power of Prolog’s pattern matcher. He discusses techniques for getting around perceived weaknesses of Prolog’s localized variables and global backtracking. Global variables can be simulated by the use of “assert” and “retract”, and the “cut” is provided to control backtracking as needed. As further empirical evidence of the usefulness of Prolog he discusses an informal experiment at Edinburgh in which two groups of students were taught AI in POP-2 (a Lisp-like language) and Prolog, respectively. “After two months, the POP-2 group was writing pattern matchers and the PROLOG group was writing naturallanguage question answerers. Once they had learned PROLOG, the low-level stuff was already there” (ibid, p. 18). McDermott concludes that Prolog is a language that competes “pretty well” with Lisp. On the subjective level Prolog is the center of considerable controversy. Some proponents have recklessly proclaimed Prolog’s virtues, thereby generating significant backwash from disbelievers. Robert Kowalski (1980, p. 44) has gone so far as to state There is only one language suitable for representing information – whether declarative or procedural – and that is first-order predicate logic. There is only one intelligent way to process information – and that is by applying deductive inference methods. The AI community might have realized this sooner if it weren’t so insular. The database community, for example, learned its lesson several years earlier. Researchers like Wendy Lehnert (1984) have responded to the smugness of such statements by replying PROLOG appeals to our intellectual insecurities and desire for scientific respectability. It appeals to a rather seductive ‘blind faith’ mentality that takes hold in the face of extremely difficult problems. It allows us to avoid truly hard problems in AI at the same time that it lends dignity to narrower issues...with diversions like PROLOG around, it is difficult to keep a clear perspective on exactly what needs to be accomplished in the AI community. Lehnert further contends that “it is not the case that PROLOG makes any real contribution to any of the [AI] problems: it merely makes it easy to program some very old ideas” (ibid, 1984). How then is one to sort out the usefulness of Prolog as a programming language in the face of such strong and contradictory claims? 2. Basis for Comparison with Other Languages. It is a generally accepted principle that all programming languages are computational equivalent in power to a Turing Machine and therefore to each other. However, this computational equivalence has long been disregarded when comparing different languages. In the SIGART Newsletter Special Issue on Knowledge Representation, Brachman and Smith (1980) present a hypothesis for discussion that “such ‘Turing equivalence’ is a vacuous notion when dealing with representation languages” (ibid 1980, p. 127). The authors go on to suggest that the usual method of showing equivalence by implementing language A in language B and vice versa does not preserve denotational correspondence (e.g. implementation does not in general preserve the identity of data structures), and therefore “does not constitute equivalence between representation languages” (ibid, p. 128). That is to say that in order for two representation languages to be equivalent they must be both behaviorally and structurally equivalent. Turing Machine equivalence is limited to behavioral equivalence. Thus, we can compare languages in terms of their structural differences. There seems to be some correspondence between the terms behavioral/structural used in the SIGART article and the control logic/data structures of actual programming languages. However, since different languages may have different control structures (e.g. recursion in Lisp, pattern matching/backtracking, in addition to recursion, in Prolog) as well as different data structures, the exact nature of this correspondence is clouded. Some researchers have gotten round the inadequacy of computational power as a basis for comparing programming languages by adopting a less well-defined notion of expressive power. According to Reddy (???, p. 195), “Expressive power, unlike computational power, is not a simple and precisely defined quality. It refers to several traits such as length of programs, ease of writing programs, readability, etc.”. These researchers concentrate on the empirical analysis of language features in the absence of sound theoretical criteria for distinguishing between languages. Perhaps, I can sum up this discussion by suggesting that since representation languages are theoretically equivalent, the only bases for comparison are empirical differences. By saying this I am suggesting that Hewitt’s theoretical arguments against the inadequacy of logic programming languages can be reduced to empirical arguments about the difficulty of using such languages to model open systems. That is, I believe it can be shown that logic programming languages are in fact capable of modeling open systems. The question is therefore not whether they can be used to model open systems, but whether or not they are suitable for doing so. Thus, this paper’s discussion of Prolog’s usefulness as a programming language and its comparison with Lisp consists maninly of an analysis of the empirical features of Prolog and its differences from Lisp. 3. Development of Prolog I am apparently not alone in thinking that the development of Prolog to date resembles the early development of another controversial programming language – Lisp. According to Cohen (1985, p. 1311) “...since its conception, Prolog has been evolving in a manner not unlike the early evolution of LISP”. Cohen goes on to note that both Prolog and Lisp are in fact still evolving. I think this development process can be viewed as a struggle between two camps: the purists (theoretically speaking) and the empiricists. In the case of Lisp it is apparent that many empirically useful constructs have been added to the language which was and continues to be based on Church’s Lambda Calculus. Most Lisp programmers begin by learning to program in Lisp and only later develop an understanding of its theoretical underpinnings. As such they are not willing to restrict themselves to the use of theoretically pure constructs when other more immediately useful constructs are available. On the other hand, there is a small group of diehard purists who consider these added constructs to contaminate the original language and reduce its theoretical elegance. Prolog faces much the same dichotomy. On the one hand, researchers like McDermott (1980, p. 18) contend that “the notion that programming in PROLOG is programming in logic is ridiculous”. And Barbuti et al. (???, p. 160) note that A fully declarative language [e.g. Prolog]...does not seem to be adequate as a machine language. In fact, both at the system and at the application level there exist software components which are intrinsically procedural. Defining them declaratively would, on one side, be unnatural, and, on the other side, make them less efficient. People who hold this view tend to look favorably upon extensions to Prolog to make it more generally useful as a programming language. On the other hand, Kowalski contends that while Prolog does have certain extralogical features (e.g. the cut, assert, retract), these features are not essential to the language. Thus, according to Kowalski (1985, p. 15), “IC PROLOG does away with the extralogical features of other PROLOG implementations. It incorporates directly a number of extensions, such as indexing, coroutining, negation by failure, conditionals and the construction and manipulation of all solutions of a subgoal which are compatible with the semantics of logic”. Kowalski contends that programming in IC PROLOG is semantically consistent with logic. Nonetheless, Kowalski concedes that Prolog is an evolving language subject to improvement and change. He notes that “PROLOG is the first and most important logicprogramming language, and it provides a tantalizing preview of the more powerful logicprogramming languages of the future” (ibid, p. 176). Indeed, much of the current literature on Prolog is devoted to articles suggesting improvements to the existing implementation. Some of these recommendations are discussed later in this paper.